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METHOD OF REQUIREMENTS TRACEABILITY BASED ON A UML 
MODEL 

CROSS - REFERENCE TO RELATED APPLICATIONS 

The present Application is based on International Application No. 
PCT/EP2004/053362, filed on December 9, 2004, which in turn corresponds to FR 
03/14718 filed on December 16, 2003, and priority is hereby claimed under 35 USC 
§119 based on these applications. Each of these applications are hereby incorporated 
by reference in their entirety into the present application. 
BACKGROUND OF THE INVENTION 

1) Field of the Invention 

The present invention pertains to a method of requirements traceability based 
on a UML (Unified Modeling Language) model. 

2) Description of Related Art 

There exist numerous methods of requirements traceability based on a model, 
but none exists for UML language models. Moreover, these known methods are 
limited to the code alone, hence they are not transposable to the UML language. 
SUMMARY OF THE INVENTION 

The present invention is aimed at a method of requirements traceability based 
on a model, which can be applied to UML modeling. 

The method in accordance with the invention is characterized in that during 
the modeling, when creating an element of a model, a requirement is immediately 
placed on this element, and same is systematically filled in with the upward 
requirement which has given rise to the creation of this element. 
BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention will be better understood on reading the detailed 
description of an embodiment, taken by way of nonlimiting example and illustrated 
by the appended drawing, in which : 

- Figure 1 is a view of a graphics interface of a RHAPSODY.TM 
(hereinafter simply "RHAPSODY") tool showing a requirement of a 
UML model, such as used by the present invention, 
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- Figure 2 is a view of the graphics interface of Figure 1, showing an 
exemplary constraint attachment, in accordance with the method of 
the invention, 

- Figure 3 is a view of the graphics interface of Figure 1, showing an 
exemplary attachment of a UML requirement, in accordance with the 
method of the invention, and 

Figure 4 is a chart showing an exemplary chaining of activities 
between the "RHAPSODY" and DOORS .TM (hereinafer simply 
"DOORS^} tools, in accordance with the method of the invention. 
DETAILED DESCRIPTION OF THE INVENTION 

It is known that the creation of a UML requirement always follows a 
modeling activity, but one should definitely not create the requirements, then model 
what is specified in these requirements, since this would inevitably lead to poor use 
of UML and of the concept of object. 

It is advisable, each time that a requirement which refines one or more 
upward requirements is created, to systematically fill in the "UpwardReq :" tag with 
the identifier of these upward requirements. Thus, the traceability of the requirements 
is managed at the time of their creation and not a posteriori on the set of 
requirements. 

A requirement is represented in the UML model (with the "RHAPSODY" 
modeling tool from the company I-LOGIX) by a UML constraint called a "UML 
Requirement requirement " . An example thereof has been represented in Figure 1 . 

All the UML Requirements requirements must be defined in the same manner 
according to the following model (or "template"): 

- the "Name" field (name of the UML Requirement requirement) must contain 
the identifier of the requirement. This identifier must make it possible to 
identify the level of the requirement. If the requirement is high-level, the 
identifier must begin with "HLR_", and if the requirement is low-level, the 
identifier must begin with "LLR_". 

- the "Stereotype" field must contain the specification level of the requirement 
(SSS (System Segment Specification) . SRS (system/Software Requirement 
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Specification) , etc. ). Specifically, the requirements defined for these various 
specification levels are all present in the same UML model. Filling in this 
stereotype field is hence the only means to differentiate the requirements as a 
function of their specification level and hence to identify toward which 
"DOORS" module (the DOORS tool is a requirements management tool from 
the company TELELOGIC) they must be redirected. 

the "Description" field (description of the UML Requirement-requirement) 
must contain the following tags : 

-"Title :", followed by the title of the requirement, 

-"Content:", followed by the text of the requirement, "Upward Req :" 
(upward request), followed by the list of the identifiers of the upward 
requirements from which this requirement stems. The identifiers must be 
separated by a comma (","). 
It will be pointed out that the set of requirements management attributes, such 
as defined in the DOORS process, do not form part of the UML model. The activity 
which consists in filling in these attributes is performed directly under DOORS, 
following the uploading of the UML Requirement;; requirements under DOORS. 

The attachment of the Requirements is done in the following manner. In the 
Rhapsody tool, the only means to associate a UML Requirement-requirement), with 
an element of the model is to attach it to this element by using the "Add New / 
Constraint" function, as represented in the example of Figure 2 (for the requirement 
"Solution"). 

This attachment function is available on all the elements of a model 
("Package", Class, Operation, Party, Case of use, State machine, State, etc ). 

Currently, the UML 1.4 standard defines that a constraint (a UML 
Requirement— requirement)_ can be attached to several UML elements, but 
RHAPSODY does not allow it. Consequently, when creating a UML Requirement 
requirement)_which has repercussions on several elements of the model, said 
requirement is attached to the common element containing the set of elements on 
which the requirement has repercussions. 
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Described below in a nonlimiting manner are two examples of such an 
attachment: 

- if two classes of one and the same "package" are relevant to the same UML 
Requirement requirement , then this UML Requirement requirement will be 
attached to the "package" containing the two classes, 

- if a UML Requirement-requirement)_ has repercussions on three methods of 
one and the same class, then this UML Requirement-requirement)_will be 
attached to the class. We have represented in Figure 3 an example of such an 
attachment of UML Requirement requirement (high-level Requirement 
"HLR_01" with two classes 3MyClass" and "MyOtherClass"). 

According to another characteristic of the invention pertaining to the 
incidence on the persi stance of the UML Requirements requirements , when an 
element of the model is deleted, all the UML Requirements requirements attached to 
this element (and to all the elements attached to this element) are likewise deleted. 
According to yet another characteristic of the invention, the UML Requirements 
requirements are exported under DOORS, following a step of UML modeling, which 
corresponds in general to a given specification level, a model containing a set of 
UML elements and of UML Requirements requirements is obtained, stereotyped 
with the corresponding specification level. When the UML model has attained a 
stable state, it is possible to then import the UML model under DOORS so as to 
perform the activities of management and requirements traceability. 

Diagrammatically represented in Figure 4 is an exemplary chaining of 
exportation activities from RHAPSODY to DOORS. In this figure, the RHAPSODY 
and DOORS tools have been represented side by side. For the first, we have 
represented the tree of a UML model and three successive development steps each 
having attained a stable modeling state, these steps being respectively referenced 
Level 1 to Level 3. As the development proceeds, the successive models are 
imported into DOORS and immediately the management and the traceability of their 
requirements is undertaken in DOORS in accordance with the method of the 
invention, as set forth above. 
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